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Sir: 

This is an appeal from an Office Action dated August 13, 2009 ("Final Office 
Action"), in which claims 1-31 were finally rejected. The Appellant respectfully requests 
that the Board of Patent Appeals and Interferences ("Board") reverses the final rejection 
of claims 1-31 of the present application. The Appellant notes that this Appeal Brief is 
timely filed within the period for reply that ends on February 19, 2010. 
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REAL PARTY IN INTEREST 
(37C.F.R.§41.37(c)(1)(i)) 

Broadcom Corporation, a corporation organized under the laws of the state of 

California, and having a place of business at 5300 California Avenue, Irvine, California 

92617, has acquired the entire right, title and interest in and to the invention, the 

application, and any and all patents to be obtained therefor, as set forth in the 

Assignment recorded at Reel 014199, Frame 0991 in the PTO Assignment Search 

room. 

RELATED APPEALS AND INTERFERENCES 
(37 C.F.R.§41.37(c)(1)(ii)) 

The Appellant is unaware of any related appeals or interferences. 

STATUS OF THE CLAIMS 
(37C.F.R. §41.37(c)(1)(iii)) 

The present application includes pending claims 1-31 . Claims 29-31 are rejected 

under 35 USC 101 for allegedly directing to non-statutory subject matter. Claims 1-4, 

15-20 and 23 are rejected under 35 USC 102(e) as anticipated by USP 6,226,680 

("Boucher"). Claims 10 and 11 are rejected under 35 USC 103(a) as being 

unpatentable over Boucher, as applied to claim 1 above, and further in view of USPP 

2002/0198934 ("Kistler"). Claims 12-14 are rejected under 35 USC 103(a) as being 

unpatentable over Boucher, as applied to claim 1 above, and further in view of Microsoft 

Winsock Direct and Protocol Offload on SANs, 03/03/2001 ("Microsoft"). Claim 21 is 

rejected under 35 USC 103(a) as being unpatentable over Boucher, as applied to claim 
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18 above, and further in view of Official Notice ("ON"). Claim 22 is rejected under 35 
USC 103(a) as being unpatentable over Boucher, as applied to claim 18 above, and 
further in view of USPP 2002/0041566 ("Yang"). Claims 5-8 and 24-28 are rejected 
under 35 USC 103(a) as being unpatentable over Boucher, as applied to claim 1 above, 
and further in view of USPP 2003/0046330 ("Hayes"). Claim 29-31 are rejected under 
35 USC 103(a) as being unpatentable over Boucher, and further in view of Callaghan 
(NFS over RDMA) ("Callaghan"). See the Final Office Action at pages 2-18. The 
Appellant identifies claims 1-31 as the claims that are being appealed. The text of the 
pending claims is provided in the Claims Appendix. 

STATUS OF AMENDMENTS 
(37C.F.R.§41.37(c)(1)(iv)) 

The Appellant has not amended any claims subsequent to the final rejection of 

claims 1-31 mailed on August 13, 2009. 

SUMMARY OF CLAIMED SUBJECT MATTER 
(37C.F.R.§41.37(c)(1)(v)) 

The Appellant has inserted Fig. 2 of the present application below, to illustrate 

several aspects of the invention. 
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II 




The invention of claim 1 is illustratively described in, for example, the "Brief 
Summary of Invention" section (see present application at page 8, lines 2-10 and 1ffl18- 
26), as well as in the description of Figs. 2-3. Independent claim 1 recites the 
following: 

4 
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A server (e.g., server 400 in Fig. 2), comprising: 

a network connector (e.g., L2 Ethernet connector 410 in Fig. 2); 

a processor (e.g., single integrated chip 550 in Figs. 2 and 3) coupled to the 
network connector (e.g., L2 Ethernet connector 410 in Fig. 2), the processor (e.g., 
single integrated chip 550 in Figs. 2 and 3) operable to process a plurality of different 
types of network traffic (e.g., to name a few: first type, common L2, L3 network traffic, 
second type, such as TCP accelerated offload traffic, third type, such as iSCSI/RDMA 
network storage traffic, fourth type, such as interprocess communication IPC traffic, fifth 
type, such as traffic relating to operating system (OS) Agnostic Management Entity or 
device, also see id fflT20-26), wherein each of said plurality of different types of network 
traffic corresponds to a different network protocol (e.g., to name a few: TCP, TCP/IP, 
iSCSI/RDMA); 

a peripheral component interface (PCI) bridge (e.g., PCI bridge 440 in Figs. 2 
and 3) coupled to the processor (e.g., single integrated chip 550 in Figs. 2 and 3); and 

a unified driver (e.g., unified driver 450 in Fig. 2) coupled to the PCI bridge (e.g., 
PCI bridge 440 in Figs. 2 and 3), the unified driver (e.g., unified driver 450 in Fig. 2) 
operable to provide drivers associated with the plurality of different types of network 
traffic (e.g., to name a few: first type, common L2, L3 network traffic, second type, such 
as TCP accelerated offload traffic, third type, such as iSCSI/RDMA network storage 
traffic, fourth type, such as interprocess communication IPC traffic, fifth type, such as 
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traffic relating to operating system (OS) Agnostic Management Entity or device, also 
see UH20-26). 

Claims 2-17 are dependent directly or indirectly upon independent claim 1 . 

The invention of claim 18 is illustratively described in, for example, the "Brief 
Summary of Invention" section (see present application at page 8, lines 2-10 and 1ffl18- 
26), as well as in the description of Figs. 2-3. Independent claim 18 recites the 
following: 

A method for network interfacing, comprising: 

handling a plurality of different types of network traffic (e.g., to name a few: first 
type, common L2, L3 network traffic, second type, such as TCP accelerated offload 
traffic, third type, such as iSCSI/RDMA network storage traffic, fourth type, such as 
interprocess communication IPC traffic, fifth type, such as traffic relating to operating 
system (OS) Agnostic Management Entity or device, also see 1ffl20-26) via a laver 2 
(L2) connector (e.g., L2 Ethernet connector 410 in Fig. 2), wherein each of said plurality 
of different types of network traffic corresponds to a different network protocol (e.g., to 
name a few: TCP, TCP/IP, iSCSI/RDMA); 

processing the different types of network traffic (e.g., to name a few: first type, 
common L2, L3 network traffic, second type, such as TCP accelerated offload traffic, 
third type, such as iSCSI/RDMA network storage traffic, fourth type, such as 
interprocess communication IPC traffic, fifth type, such as traffic relating to operating 
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system (OS) Agnostic Management Entity or device, also see id ffl|20-26) via a layer 2 
(L2) connector (e.g., L2 Ethernet connector 410 in Fig. 2) in a single chip (e.g., single 
integrated chip 550 in Figs. 2 and 3); and 

determining which of the different types of network traffic accesses software 
services (e.g., TCP stack 460, socket switch services 470, SCSI miniport service 510 
and RDMA service 520, also see id 1f25) via a single data path (e.g., PCI bridge 440 in 
Figs. 2 and 3). 

Claims 19-23 are dependent directly or indirectly upon independent claim 18. 

The invention of claim 24 is illustratively described in, for example, the "Brief 
Summary of Invention" section (see present application at page 8, lines 2-10 and 1ffl18- 
26), as well as in the description of Figs. 2-3. Independent claim 24 recites the 
following: 

A method for network interfacing, comprising: 

handling a plurality of different types of network traffic (e.g., to name a few: first 
type, common L2, L3 network traffic, second type, such as TCP accelerated offload 
traffic, third type, such as iSCSI/RDMA network storage traffic, fourth type, such as 
interprocess communication IPC traffic, fifth type, such as traffic relating to operating 
system (OS) Agnostic Management Entity or device, also see id ffl|20-26) via a single 
Ethernet connector (e.g., L2 Ethernet connector 410 in Fig. 2), wherein each of said 
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plurality of different types of network traffic corresponds to a different network protocol 
(e.g., to name a few: TCP, TCP/IP, iSCSI/RDMA); 

processing the plurality of different types of network traffic (e.g., to name a few: 
first type, common L2, L3 network traffic, second type, such as TCP accelerated offload 
traffic, third type, such as iSCSI/RDMA network storage traffic, fourth type, such as 
interprocess communication IPC traffic, fifth type, such as traffic relating to operating 
system (OS) Agnostic Management Entity or device, also see id 1ffl20-26) using a layer 
2 (L2) processor (e.g., L2 NIC 430 in Fig. 2), a layer 3 (L3) processor (e.g., TCP 
processor 490 in Fig. 2), a layer 4 (L4) processor (e.g., iSCSI/RDMA processor 500 in 
Fig. 2) and an upper layer protocol (ULP) processor; and 

providing a unified data and control path (e.g., unified driver 450 coupled to the 
PCI bridge 440 in Figs. 2 and 3). 

Claims 25-28 are dependent directly or indirectly upon independent claim 24. 

The invention of claim 29 is illustratively described in, for example, the "Brief 
Summary of Invention" section (see present application at page 8, lines 2-10 and 1ffl18- 
26), as well as in the description of Figs. 2-3. Independent claim 29 recites the 
following: 

A unified driver (e.g., unified driver 450 in Figs. 2 and 3), comprising: 

a computer program executable on a computer system (see id ffl|37-38), having 
at least one code section for arranging and processing network traffic, wherein the at 
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least one code section causes the computer system to perform steps comprising: 
executing said at least one code section from said unified driver in said computer 
system to handle a plurality of different types of network traffics (e.g., to name a few: 
first type, common L2, L3 network traffic, second type, such as TCP accelerated offload 
traffic, third type, such as iSCSI/RDMA network storage traffic, fourth type, such as 
interprocess communication IPC traffic, fifth type, such as traffic relating to operating 
system (OS) Agnostic Management Entity or device, also see id 1ffl20-26) and/or 
network services (e.g., TCP stack 460, socket switch services 470, SCSI miniport 
service 510 and RDMA service 520, also see id 1J25) via a single PCI bridge (e.g., PCI 
bridge 440 in Figs. 2 and 3), wherein each of said plurality of different types of network 
traffic (e.g., to name a few: first type, common L2, L3 network traffic, second type, such 
as TCP accelerated offload traffic, third type, such as iSCSI/RDMA network storage 
traffic, fourth type, such as interprocess communication IPC traffic, fifth type, such as 
traffic relating to operating system (OS) Agnostic Management Entity or device, also 
see id ffl|20-26) corresponds to a different network protocol (e.g., to name a few: TCP, 
TCP/IP, iSCSI/RDMA), and the network services comprise two or more of a socket 
service, storage service, RDMA service or keyboard/video/mouse service. 

Claims 30-31 are dependent directly or indirectly upon independent claim 29. 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
(37C.F.R.§41.37(c)(1)(vi)) 

The present application includes pending claims 1-31 . Claims 29-31 are rejected 

under 35 USC 101 for allegedly directing to non-statutory subject matter. Claims 1-4, 

15-20 and 23 are rejected under 35 USC 102(e) as anticipated by USP 6,226,680 

("Boucher"). Claims 10 and 11 are rejected under 35 USC 103(a) as being 

unpatentable over Boucher, as applied to claim 1 above, and further in view of USPP 

2002/0198934 ("Kistler"). Claims 12-14 are rejected under 35 USC 103(a) as being 

unpatentable over Boucher, as applied to claim 1 above, and further in view of Microsoft 

Winsock Direct and Protocol Offload on SANs, 03/03/2001 ("Microsoft"). Claim 21 is 

rejected under 35 USC 103(a) as being unpatentable over Boucher, as applied to claim 

18 above, and further in view of Official Notice ("ON"). Claim 22 is rejected under 35 

USC 103(a) as being unpatentable over Boucher, as applied to claim 18 above, and 

further in view of USPP 2002/0041566 ("Yang"). Claims 5-8 and 24-28 are rejected 

under 35 USC 103(a) as being unpatentable over Boucher, as applied to claim 1 above, 

and further in view of USPP 2003/0046330 ("Hayes"). Claim 29-31 are rejected under 

35 USC 103(a) as being unpatentable over Boucher, and further in view of Callaghan 

(NFS over RDMA) ("Callaghan"). See the Final Office Action at pages 2-18. The 

Appellant identifies claims 1-31 as the claims that are being appealed. The text of the 

pending claims is provided in the Claims Appendix. 
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ARGUMENT 
(37C.F.R.§41.37(c)(1)(vii)) 

I. Rejection to Claims 29-31 under 35 U.S.C. § 101 

Claim 29 recites "A unified driver, comprising: a computer program executable 
on a computer system, having at least one code section causes the computer 
system to perform steps comprising: executing said at least one code section from 
said unified driver in said computer system to handle..." The Examiner (see Final 
Office Action in page 4) alleges that the driver comprises mere program code, and does 
not comprise any hardware elements in the computer system. The Appellant 
respectfully disagrees, and points out that claim 29 recites that the unified driver 
executes the program codes in the computer system . In this regard, the driver 
program code is tied to a computer system, which also cause the computer system to 
perform the recited steps. Therefore, the Appellant maintains that the recited unified 
driver is statutory subject matter and is patentable. The Appellant respectfully requests 
that the rejection to claim 29 under 35 USC 101 be withdrawn. Likewise, claims 30-31 
depend from claim 29, and are submitted to be also patentable. 

REJECTION UNDER 35 U.S.C. § 102(e) 

MPEP2131 states: 

"[a] claim is anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a single prior art 
reference." See MPEP at 2131 (internal citation omitted). Furthermore, 
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"[t]he identical invention must be shown in as complete detail as is 
contained in the ... claim." See id. (internal citation omitted). 



II. Boucher Does Not Anticipate Claim 1-4, 15-20 and 23 

The Appellant turns to the rejection of claims 1 -4, 1 5-20 and 23 under 35 U.S.C. 
§ 102(e) as being anticipated by Boucher. Without conceding that Boucher qualifies as 
prior art under 35 U.S.C. 102(e), the Appellant respectfully traverses this rejection as 
follows. 

A. Independent Claims 1 and 18 

With regard to the rejection of independent claim 1 under 35 U.S.C. § 102(e), the 
Appellant submits that Boucher does not disclose or suggest at least the limitation of 
"processor operable to process a plurality of different types of network traffic, wherein 
each of said plurality of different types of network traffic corresponds to a different 
network protocol ," as recited in the Appellant's claim 1 . 

In the Final Office Action, the Examiner asserts Boucher discloses the following: 

"For claim 1 , Boucher discloses a server, comprising: 

a network connector (fig. 13, col. 16 lines 6-12, network line 210, four 
network lines are presented for different conduits, but each of them is a 
media independent interface); 

a processor coupled to the network connector (fig. 13, microprocessor 
470, col. 16 line 62-col. 17 line 13), the processor being operable to 
process a plurality of different types of network traffic, wherein each of 
said plurality of different types of network traffic corresponds to a different 
network protocol (abstract, col. 3 lines 35-67, col. 6 lines 33-55, col. 13 
lines 24-35, the intelligent network interface card INIC's processor 
supports an fast path candidate traffics and slow path traffics by 
identifying input packet protocol types); 
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• a peripheral component interface (PCI) bridge coupled to the processor 
(fig. 13, PCI bus interface unit); and 

• a unified driver coupled to the PCI bridge, the unified driver being 
operable to provide drivers associated with the plurality of different types 
of network traffic (fig. 6 and 10, PCI bridge 157 connected to protocol 
stack with driver, col. 14 I. 9-13, INIC miniport driver determines 
whether the traffic is fast path candidate offload traffic or non-fast 
path IP and/or Ethernet traffic). 

See the Office Action in pages 5-6 (emphasis added). In order to help 
understanding, the Appellant has inserted Boucher's Figs. 13 and 4D for reference: 
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The Examiner relies for support on Boucher's fig. 13, and equates Boucher's 
MAC-A 402 to MAC-D, microprocessor 470 and PCI bus interface 468 to Appellant's 
"network connector", "processor" and "PCI bridge", respectively. The Examiner also 
equates Boucher's packets routed to slow path processing (e.g., path 56 via the 
protocol stack 44 in Boucher's Fig. 4A) and packets routed to fast path processing (e.g., 
path 72 by-passing the protocol stack 44 in Boucher's Fig. 4C) to Appellant's "plurality 
of different types of network traffic corresponds to different network protocol," as recited 
in claim 1. Specifically, the Examiner relies for support on the following citation of 
Boucher: 

"When a message packet or frame is received 47 from a network by the 
CPD, it is first validated by a hardware assist. This includes determining 
the protocol types of the various layers, verifying relevant checksums, and 
summarizing 57 these findings into a status word or words. Included in 
these words is an indication whether or not the frame is a candidate for 
fast-path data flow. Selection 59 of fast-path candidates is based on 
whether the host may benefit from this message connection being handled 
by the CPD, which includes determining whether the packet has header 
bytes denoting particular protocols, such as TCP/IP or SPX/IPX for 
example. The small percent of frames that are not fast-path candidates 
are sent 61 to the host protocol stacks for slow-path protocol processing. 
Subsequent network microprocessor work with each fast-path candidate 
determines whether a fast-path connection such as a TCP or SPX CCB is 
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already extant for that candidate, or whether that candidate may be used 
to set up a new fast-path connection, such as for a TTCP/IP transaction. 
The validation provided by the CPD provides acceleration whether a frame 
is processed by the fast-path or a slow-path, as only error free, validated 
frames are processed by the host CPU even for the slow-path 
processing." 



See Boucher at col. 6, lines 33-55. In the above citation, the Examiner relied on 
Boucher's flow chart (step 59) in Fig. 3, which identifies the packet being a fast path or 
slow path candidate based on the packet header bytes which denote particular 
protocols. In other words, the Examiner alleges that the fast path packet header 
protocol and the slow path header protocol denote different network traffic types . 

The Appellant respectfully disagrees, and points out that MPEP 2141.02-VI 
states that "prior art must be considered in its entirety, including disclosures that teach 
away from the claims". Namely, the Appellant refers the Examiner to another portion of 
Boucher's disclosure, which contrasts the above allegation of the Examiner. For 
example, Boucher states the following: 

"In effect, the fast-path replaces the states that are traditionally found 
in several layers of a conventional network stack with a single state 
machine encompassing all those layers, in contrast to conventional rules 
that require rigorous differentiation and separation of protocol layers. The 
host retains a sequential protocol processing stack which can be 
employed for setting up a fast-path connection or processing 
message exceptions. The specialized micro-processor and the host 
intelligently choose whether a given message or portion of a message is 
processed by the microprocessor or the host stack." 



See Boucher col. 3, line 60 - col. 4, line 3 (emphasis added). Boucher discloses 
that the fast-path processing is a replacement of the traditional protocol stack 
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processing path. Furthermore, Boucher also discloses that the host retains the same 
protocol stack processing for setting up a fast-path connection for future processing of 
the fast-path packets or to the message exceptions. In other words, there is no 
difference in terms of "network traffic type" between Boucher's fast-path candidate 
packet and the traditional slow-path candidate packet. Boucher discloses that both the 
fast-path candidate packet and the slow-path candidate packet are of the same "offload" 
network traffic type, but may be processed with different paths for the purpose of 
processing efficiency only, and not because of different network traffic types, as alleged 
by the Examiner. 

Accordingly, Boucher's disclosure of the particular protocol indicated by the 
header bytes in the respective packets, is only for purposes of identifying which path the 
packet may be routed for efficient processing. This is further evidenced by Boucher's 
Fig. 4D, which illustrates that a fast path candidate may be processed by the traditional 
slow-path via the protocol stack 44 in an exceptional case. 

Even if we assume, arguendo, that Boucher's fast-path candidate packet's 
header protocol indicates a different network traffic type than the slow-path protocol 
network traffic type, then the fast-path protocol network traffic type would not be 
recognized and processed by the traditional slow-path protocol stack in the host (which 
allegedly only processes the slow-path traffic network protocol). Therefore, based on 
the above rationale, the Appellant maintains that the Examiner's interpretation that 
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Boucher's fast-path candidate packet is of a different network traffic type than the 
traditional slow-path candidate packet is, in fact, contrary to Boucher's disclosure. 

The Examiner (see Final Office Action in page 2) also argued that Boucher's 
disclosure of "determining whether the packets packet has header bytes denoting 
particular protocols, such as (TCP/IP or SPX/IPX)" constitutes "different types of 
network traffic" (see Boucher at col. 6, lines'! 3-32). The Examiner is again referred to 
the Appellant's above arguments, namely, that Boucher discloses that the fast-path 
processing is merely a replacement path for efficiency purposes only , and not 
because it is a different network traffic type . Boucher, in Fig. 3 (step 57) determines 
whether the incoming frame contains an indication allowing fast-path processing. If 
such an indication is absent, then slow-path processing is allowed. In this regard, the 
fast-path candidate packet can equally be processed by the slow-path protocol stack. 
In addition, Boucher simply discloses that the incoming frame may be from similar 
protocols (e.g., TCP/IP or SPX/IPX), but the fact remains that for a given incoming 
frame, the fast-path and the slow-path processing apply to the same incoming frame of 
a given network traffic type (i.e., there is no processing of "different types of network 
traffic"). Therefore, the Examiner's above argument that the (TCP/IP or SPX/IPX)" 
constitutes "different types of network traffic", is not relevant because regardless of 
whether the incoming frame is TCP/IP or SPX/IPX, fast- and slow-path processing apply 
to the same traffic type. 

Based on the foregoing rationale, the Appellant maintains that Boucher does not 
disclose or "...the processor operable to process a plurality of different types of network 
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traffic, wherein each of said plurality of different types of network traffic 
corresponds to a different network protocol ," as recited in the Appellant's claim 1 . 
The Appellant submits that claim 1 is allowable. Likewise, independent claim 18 is 
similar in many respects to claim 1, and therefore is also submitted to be allowable. 
The Appellant respectfully requests that the rejection of independent claims 1 and 18 
under 35 U.S.C. § 102(e) be withdrawn. 

B. Dependent Claims 2-4, 15-20 and 23 

Based on at least the foregoing, the Appellant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by Boucher 
has been overcome and should be withdrawn. The Appellant submits that claims 2-4, 
15-20 and 23 depend directly or indirectly from the independent claims 1 and 18, and 
are, consequently, also respectfully submitted to be allowable, and requests that the 
rejection under 35 U.S.C. § 102(e) be withdrawn. 

C. Rejection of Dependent Claims 3 and 19 

The Examiner stated the following in the Final Office Action (see page 7): 

"For claim 3, Boucher further discloses the plurality of different types of 
network traffic comprises two or more of common Ethernet traffic, 
offload traffic, storage traffic, interprocess communication (IPC) traffic, 
management traffic and remote direct memory access (RDMA) traffic 
(abstract, col. 3 lines 35-67, col. 13 lines 24-35, the intelligent network 
interface card INIC's processor supports an offload traffic protocols via fast 
path and regular IP traffic protocols via a slow path, or Ethernet traffic and 
offload traffic)." 
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The Appellant has reviewed the Examiner's citation in Boucher's abstract, col. 3, 
lines 35-67, and col. 13, lines 24-35, and points out that Boucher discloses only one 
type of network traffic, i.e. the offload traffic by fast path (via the INIC processor and 
DMA controller) or slow path (via the host protocol stack). Boucher simply does not 
disclose other network traffic types, namely, "the storage traffic, IPC, 
management traffic and RDMA traffic," as recited in Appellant's claim 3. Claim 3 is 
submitted to be allowable based at least on this rationale. Claim 19 is allowable for at 
least the same rationale as discussed with respect to claim 3. 

D. Rejection of Dependent Claim 15 

The Examiner stated the following in the Final Office Action (see page 7): 

"For claim 15, Boucher further discloses the processor or the PCI bridge 
determines which of the different types of network traffic accesses a 
particular service provided by the server (fig. 10 and 11, col. 141 .9-13 and 
61-66, INIC miniport driver determines whether the traffic is fast path 
offload traffic protocol and slow path traffic protocol)." 

The Appellant refers the Examiner to the same argument set forth above with 
respect to claim 1, that the fast path and the slow path traffic are not different network 
traffic types. In this regard, Boucher does not disclose or suggest "the processor or the 
PCI bridge determines which of the different types of network traffic accesses a 
particular service provided by the server," as recited in Appellant's claim 15. Claim 15 is 
submitted to be allowable based on this rationale. 
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E. Rejection of Dependent Claims 17 and 23 

The Examiner stated the following in the Final Office Action (see page 7): 

"For claim 17, Boucher further discloses the processor, the PCI bridge or 
the unified driver provides a unified data and control path (fig. 10 and 11, 
col. 14 I. 9-13 and 61-66, INIC miniport driver determines whether the 
traffic is fast path offload traffic protocol and slow path IP traffic protocol)." 



The Appellant refers the Examiner to the same argument set forth above with 
respect to claim 1, that the fast path and the slow path traffic are not different network 
traffic types. In this regard, Boucher does not disclose or suggest "the processor, the 
PCI bridge or the unified driver provides a unified data and control path," as recited in 
Appellant's claim 17. Claim 17 is submitted to be allowable based at least on this 
rationale. Claim 23 is also allowable for the same rationale discussed with respect to 
claim 17. 



REJECTION UNDER 35 U.S.C. § 103 

In order for a prima facie case of obviousness to be established, the Manual of 

Patent Examining Procedure, Rev. 6, Sep. 2007 ("MPEP") states the following: 

The key to supporting any rejection under 35 U.S.C. 103 is the clear articulation 
of the reason(s) why the claimed invention would have been obvious. The 
Supreme Court in KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385, 1396 
(2007) noted that the analysis supporting a rejection under 35 U.S.C. 103 should 
be made explicit. The Federal Circuit has stated that "rejections on obviousness 
cannot be sustained with mere conclusory statements; instead, there must be 
some articulated reasoning with some rational underpinning to support the legal 
conclusion of obviousness." 

See the MPEP at § 2142, citing In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 

(Fed. Cir. 2006), and KSR International Co. v. Teleflex Inc., 82 USPQ2d at 1396 
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(quoting Federal Circuit statement with approval). Further, MPEP § 2143.01 states that 

"the mere fact that references can be combined or modified does not render the 

resultant combination obvious unless the results would have been predictable to one of 

ordinary skill in the art" (citing KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385, 

1396 (2007)). Additionally, if a prima facie case of obviousness is not established, the 

Appellant is under no obligation to submit evidence of nonobviousness: 

The examiner bears the initial burden of factually supporting any prima facie 
conclusion of obviousness. If the examiner does not produce a prima facie case, 
the applicant is under no obligation to submit evidence of nonobviousness. 

See MPEP at §2142. 

III. The Proposed Combination of Boucher and Kistler, Does Not Render Claims 

10 and 11 Unpatentable 

Claims 10 and 11 are rejected under 35 USC 103(a) as being unpatentable over 
Boucher, as applied to claim 1 above, and further in view of Kistler. 

Based on at least the foregoing, the Appellant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by Boucher 
has been overcome and should be withdrawn. Kistler does not overcome Boucher's 
deficiency in disclosing the Appellant's limitation. The Appellant submits that claims 10- 

11 depend directly or indirectly from the independent claim 1, and are, consequently, 
also respectfully submitted to be allowable, and requests that the rejection under 35 
U.S.C. § 103(a) be withdrawn. 



21 



Application Serial N° 10/652,327 
Appeal Brief in Response to Final Office Action of August 13, 2009 



A. Rejection of Dependent Claims 10 and 11 

The Examiner stated the following in the Final Office Action (see page 10): 

"For claims. 10 and 11, Boucher discloses the invention as in claim 1. 
Boucher does not disclose a server management agent coupled to the 
processor that is coupled to a keyboard and/or video and/or mouse 
service. However, Kistler discloses the same (fig. 3 keyboard and mouse 
connected to an emulator that is coupled to a NIC). 

Therefore, it would have been obvious for one skilled in the art at the time 
of the invention to combine the teachings of Boucher and Kistler to provide 
console interaction handling over the network (Kistler, abstract) "For claim 
15, Boucher further discloses the processor or the PCI bridge determines 
which of the different types of network traffic accesses a particular service 
provided by the server (fig. 10 and 11, col. 141.9-13 and 61-66, INIC 
miniport driver determines whether the traffic is fast path offload traffic 
protocol and slow path traffic protocol)." 



The Examiner seems to equate Kistler's emulator 324 to Appellant's "server 
management agent". The Appellant respectfully disagrees, and points out that Kistler's 
emulator is merely an application (see Kistler at 1J0025) running within the operating 
system 322, and Kistler does not disclose or suggest that the emulator 324 performs 
any "server management" functions. In this regard, Kistler does not disclose or suggest 
"a server management agent coupled to the processor," as recited in claim 10 or "the 
server management agent is coupled to a keyboard and/or video and/or mouse 
service," as recited in claim 11. Claims 10 and 11 are submitted to be allowable. 
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IV. The Proposed Combination of Boucher and Microsoft, Does Not Render 
Claims 12 - 14 Unpatentable 

Claims 12-14 are rejected under 35 USC 103(a) as being unpatentable over 

Boucher, as applied to claim 1 above, and further in view of Microsoft. 

Based on at least the foregoing, the Appellant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by Boucher 
has been overcome and should be withdrawn. Microsoft does not overcome Boucher's 
deficiency in disclosing the Appellant's limitation. In addition, the Appellant submits that 
claims 12-14 depend directly or indirectly from independent claim 1, and are, 
consequently, also respectfully submitted to be allowable. The Appellant respectfully 
requests that the rejection under 35 U.S.C. § 103(a) be withdrawn. 



A. Rejection of Dependent Claim 14 

The Examiner stated the following in the Final Office Action (see pages 10-11): 

"For claim 14, Boucher does not disclose the unified driver is coupled to a 
software TCP processor and to a socket service switch, wherein the 
software TCP processor is coupled to the socket service switch However, 
Microsoft discloses the unified driver is coupled to a software TCP 
processor and to a socket service switch, wherein the software TCP 
processor is coupled to the socket service switch (Microsoft, fig. 1, a 
socket switch between a TCP/IP socket provider and a SAN 
provider), and wherein the socket service switch is coupled to a socket 
service (Microsoft, fig. 1, switch coupled to socket application). 

Therefore, it would have been obvious for one skilled in the art at the time 
of the invention to combine the teachings of Boucher and Microsoft to 
provide WinSock socket service switch to a TCP/I P-offload-enabled NIC 
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card of Boucher in order to further enhance the card with more 
functionalities such as RDMA traffic support." 

In order to help understanding, the Appellant has inserted Microsoft's Fig. 1 for 
reference: 




The Examiner equates Microsoft's SAN provider to Appellant's "unified driver". 
However, the Appellant points out that Microsoft's SAN provider (the alleged "unified 
driver") is coupled to only the service provided through the Winsock Direct. In this 
regard, Microsoft does not disclose or suggest "a plurality of services coupled to the 
unified driver," as recited in Appellant's claim 12. 
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In addition, the Examiner also equates Microsoft's TCP/IP socket provider, switch 
and socket application to Appellant's "software TCP processor", "socket service switch" 
and "socket service", respectively. Even though Microsoft's TCP/IP socket provider (the 
alleged "software TCP processor") is coupled to the switch (the alleged "socket service 
switch"), and the switch (the alleged "socket service switch") is coupled to the socket 
application (the alleged "socket service"), nevertheless, Microsoft's TCP/IP socket 
provider (the alleged "software TCP processor") is not coupled to the SAN provider 
(the alleged "unified driver"). It is clear that the switch (the alleged "socket service 
switch") has created two separate paths, namely the conventional path to the TCP/IP 
sockets provider (the alleged "software TCP processor"), and the Winsock direct path, 
which is coupled to the SAN Provider (the alleged "unified driver"). 

In this regard, Microsoft at least does not disclose or suggest "the unified driver is 
coupled to a software TCP processor and to a socket service switch," as recited in 
Appellant's claim 14. Claim 14 is submitted to be allowable based on this rationale. 

B. Rejection of Dependent Claim 12 

The Examiner stated the following in the Final Office Action (see page 11): 

"For claim 12, Boucher-Microsoft discloses the invention as in claim 14. 
Boucher-Microsoft further discloses a plurality of services coupled to the 
unified driver (Microsoft, fig. 1, p. 5 lines 7-8, socket service, RDMA 
service)." 
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The Examiner is referred to Appellant's argument in claim 14 above, namely, 
Microsoft's SAN provider (the alleged "unified driver") is coupled to only the service 
provided through the Winsock Direct. In this regard, Microsoft does not disclose or 
suggest "a plurality of services coupled to the unified driver," as recited in Appellant's 
claim 12. Claim 12 is submitted to be allowable based on this rationale. 



C. Rejection of Dependent Claim 13 

The Examiner stated the following in the Final Office Action (see page 11): 

"For claim 13, Boucher-Microsoft discloses the invention as in claim 14. 
Boucher-Microsoft further discloses the particular service comprises at 
least one of a socket service, a SCSI miniport service, an RDMA service 
and/or a keyboard and/or video and/or mouse service (Microsoft, fig. 1 , p. 
5 lines 7-8, socket service, RDMA service)." 



Claim 13 is dependent on claim 12, and is submitted to be allowable based on 
the rationale stated above regarding claim 12. 



D. The Rejection of Claim 21 Using Official Notice 

Claim 21 is rejected under 35 USC 103(a) as being unpatentable over Boucher, 
as applied to claim 18 above, and further in view of Official Notice (hereinafter "ON"). 

The Examiner states the following in page 12 of the Final Office Action: 

Boucher does not disclose employing time division multiplexing to determine 
which of the different types of network traffic access the software services via the 
single data path. 
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However, Official Notice is taken that it is well known in the art how to employ 
time division multiplexing (TDM) to transmit multiple traffics over one channel in 
different timeslots. Microsoft Computer Dictionary (fifth edition) defines time 
division multiplexing as a form of multiplexing in which transmission time is 
broken into segments, each of which carries one segment of one signal or traffic 
type. 



The Appellant points out that the Examiner has cited Microsoft Computer 
Dictionary (fifth edition) in support of the Official Notice and to show TDM to transmit 
segments of one signal or traffic. The Applicant specifically challenged the perceived 
and explicit assertions of Official Notice with regard to dependent claim 21, namely, 
"...time division multiplexing to determine which of the different types of network 
traffic access the software services via the single data path " is well known in the art. 
In response, the Examiner (see Final Office Action in page 4) stated the following: 

"TDM is a type of multiplexing in which two or more signals or bit 
streams are transferred apparently simultaneously as sub-channels 
in one communication channel, but are physically taking turns on the 
channel. The time domain is divided into several recurrent timeslots of 
fixed length, one for each sub-channel. Given that TDM is so well known 
in the art, it would have been obvious for one skilled in the art at the time 
of the invention to combine the teachings of Boucher and what is well 
known in the art to determine which of the different types of network 
traffic at which timeslot to access the data path by allotting multiple 
traffic segments of different types over one channel in different time 
slots using TDM in order to minimize cost and complexity of building 
multiple channels unnecessarily." 

The Examiner, in effect, argued that TDM is well known for time multiplexing in a 
single channel, for transfer of two or more signals or bit streams. However, 
Applicant's claim recites "time division multiplexing to determine which of the different 
types of network traffic access the software services via the single data path ". In 
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other words, the claimed TDM is for accessing software services via the single 
channel, and not for transfer of signals or bit streams, as alleged by the Examiner. 
In this regard, the Applicant maintains that TDM is not well known for " accessing 
software services via the single channel," as recited in Applicant's claim 21 . 

The Appellant submits that claim 21 is allowable. In addition, based on at least 
the foregoing, the Appellant believes the rejection of the independent claims 1 and 18 
under 35 U.S.C. § 102(e) as being anticipated by Boucher has been overcome and 
should be withdrawn. The Appellant submits that claim 21 depends directly or indirectly 
from independent claim 18, and is, consequently, also respectfully submitted to be 
allowable, and requests that the rejection under 35 U.S.C. § 103(a) be withdrawn. 

V. The Proposed Combination of Boucher and Yang Does Not Render Claim 22 
Unpatentable 

Claim 22 is rejected under 35 USC 103(a) as being unpatentable over Boucher, 
as applied to claim 1 8 above, and further in view of Yang. 

Based on at least the foregoing, the Appellant believes the rejection of the 
independent claims 1 and 18 under 35 U.S.C. § 102(e) as being anticipated by Boucher 
has been overcome and should be withdrawn. Yang does not overcome Boucher's 
deficiency in disclosing the Appellant's limitation. In addition, the Appellant submits that 
claim 22 depends directly or indirectly from independent claim 18, and is, consequently, 
also respectfully submitted to be allowable, and requests that the rejection under 35 
U.S.C. § 103(a) be withdrawn. 
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A. Rejection of Dependent Claim 22 

The Examiner stated the following in the Final Office Action (see page 13): 



"For claim 22, the claim is rejected for the same rationale as in claim 18. 
Boucher does not disclose dynamically allocating fixed resources among 
the different types of network traffic. 

However, Yang discloses dynamic and fixed resource allocation for time 

division multiplexing (abstract) It would have been obvious for one skilled 
in the art at the time of the invention to combine the teachings of Boucher 
and Yang to allocate fixed resources among traffic types to allow optimize 
the use of resource such as service rate while maintaining quality of 
services (Yang, [0018])" 

The Appellant points out that Yang's dynamic scheduling of the data packets 
(see abstract and U0018) pertain to the physical data L2 level only. In this regard, Yang 
does not disclose "dynamically allocating fixed resources between among the different 
types of network traffic," as recited in claim 22. Claim 22 is submitted to be allowable 
based on this rationale. 

VI. The Proposed Combination of Boucher and Hayes Does Not Render Claims 
5-8 and 24-28 Unpatentable 

Claims 5-8 and 24-28 are rejected under 35 USC 103(a) as being unpatentable 

over Boucher, as applied to claim 1 above, and further in view of Hayes. 

Regarding the rejection of independent claim 24, the Appellant submits that the 
same rationale supporting the allowability of claim 1 is applicable, that the fast path and 
slow path packets handled by Boucher's MAC 402 are not different network traffic 
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types. Hayes does not overcome Boucher's deficiency in disclosing the Appellant's 
limitation. Based on at least the foregoing, the Appellant believes the rejection of the 
independent claim 24 under 35 U.S.C. § 103(a) as being anticipated by Boucher in view 
of Hayes has been overcome and should be withdrawn. In addition, the Appellant 
submits that claims 5-8 and 25-28 depend directly or indirectly from the independent 
claims 1 and 24, and are, consequently, also respectfully submitted to be allowable, and 
requests that the rejection under 35 U.S.C. § 103(a) be withdrawn. 

VII. The Proposed Combination of Boucher and Callaghan Does Not Render 
Claims 29-31 Unpatentable 

Claims 29-31 are rejected under 35 USC 103(a) as being unpatentable over 

Boucher, and further in view of Callaghan. 

Regarding the rejection of independent claim 29, the Appellant submits that the 
same rationale supporting the allowability of claim 1 is applicable, that the fast path and 
slow path packets handled by the PCI bridge 157 and INIC miniport driver 306 are not 
different network traffic type. Callaghan does not overcome Boucher's deficiency in 
disclosing the Appellant's limitation. Based on at least the foregoing, the Appellant 
believes the rejection of the independent claim 29 under 35 U.S.C. § 103(a) as being 
anticipated by Boucher in view of Callaghan has been overcome and should be 
withdrawn. In addition, the Appellant submits that claims 30-31 depend from the 
independent claim 29, and are, consequently, also respectfully submitted to be 
allowable, and requests that the rejection under 35 U.S.C. § 103(a) be withdrawn. 
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The Appellant reserves the right to argue additional reasons beyond those set 
forth herein to support the allowability of claims 1-31 should such a need arise. 
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CONCLUSION 

For at least the foregoing reasons, the Appellant submits that claims 1-31 
are in condition for allowance. Reversal of the Examiner's rejection and issuance 
of a patent on the application are therefore requested. 

The Commissioner is hereby authorized to charge $540 (to cover the Brief 
on Appeal Fee) and any additional fees or credit any overpayment to the deposit 
account of McAndrews, Held & Malloy, Ltd., Account No. 13-0017. 

Respectfully submitted, 



Date: February 19, 2010 / Frankie W. Wong / 

Frankie W. Wong 
Registration No. 61,832 
Patent Agent for Appellant 



McAndrews, Held & Malloy, Ltd. 
500 West Madison Street, 34th Floor 
Chicago, Illinois 60661 
(312)775-8093 (FWW) 
Facsimile: (312) 775-8100 



32 



Application Serial N° 10/652,327 
Appeal Brief in Response to Final Office Action of August 13, 2009 



CLAIMS APPENDIX 
(37C.F.R.§41.37(c)(1)(viii)) 

1 . A server, comprising: 
a network connector; 

a processor coupled to the network connector, the processor operable to process 
a plurality of different types of network traffic, wherein each of said plurality of different 
types of network traffic corresponds to a different network protocol; 

a peripheral component interface (PCI) bridge coupled to the processor; and 
a unified driver coupled to the PCI bridge, the unified driver operable to provide 
drivers associated with the plurality of different types of network traffic. 

2. The server according to claim 1 , wherein the network connector comprises 
an Ethernet connector. 

3. The server according to claim 1 , wherein the plurality of different types of 
network traffic comprises two or more of common Ethernet traffic, offload traffic, storage 
traffic, interprocess communication (IPC) traffic, management traffic and/or remote 
direct memory access (RDMA) traffic. 

4. The server according to claim 1 , wherein the processor comprises a single 
integrated chip. 

5. The server according to claim 1, wherein the processor comprises a layer 
2 network interface card (L2 NIC), a transmission control protocol (TCP) processor and 
a ULP processor. 

6. The server according to claim 5, wherein the TCP processor provides 
layer 3 processing and layer 4 processing. 
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7. The server according to claim 5, wherein the TCP processor is shared by 
two or more of TCP offload traffic, Internet small computer system interface (iSCSI) 
traffic and/or RDMA traffic. 

8. The server according to claim 5, wherein the ULP processor provides 
iSCSI processing. 

9. The server according to claim 5, wherein the ULP processor provides 
RDMA processing. 

10. The server according to claim 1, comprising: 

a server management agent coupled to the processor. 

1 1 . The server according to claim 1 , wherein the server management agent is 
coupled to a keyboard and/or video and/or mouse service. 

12. The server according to claim 1, comprising: 
a plurality of services coupled to the unified driver. 

13. The server according to claim 12, wherein the plurality of services 
comprises two or more of a socket service, a SCSI miniport service, an RDMA service 
and/or a keyboard and/or video and/or mouse service. 

14. The server according to claim 1 , 

wherein the unified driver is coupled to a software TCP processor and to a socket 
service switch, 

wherein the software TCP processor is coupled to the socket service switch, and 
wherein the socket service switch is coupled to a socket service. 
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15. The server according to claim 1, wherein the processor or the PCI bridge 
determines which of the different types of network traffic accesses a particular service 
provided by the server. 

16. The server according to claim 15, wherein the particular service comprises 
one or more of a socket service, a SCSI miniport service, an RDMA service and/or a 
keyboard and/or video and/or mouse service. 

17. The server according to claim 1 , wherein the processor, the PCI bridge or 
the unified driver provides a unified data and control path. 

18. A method for network interfacing, comprising: 

handling a plurality of different types of network traffic via a layer 2 (L2) 
connector, wherein each of said plurality of different types of network traffic corresponds 
to a different network protocol; 

processing the different types of network traffic in a single chip; and 
determining which of the different types of network traffic accesses software 
services via a single data path. 

19. The method according to claim 18, wherein the plurality of different types 
of network traffic comprises two or more of common Ethernet traffic, offload traffic, 
storage traffic, interprocess communication (IPC) traffic, management traffic and/or 
remote direct memory access (RDMA) traffic. 

20. The method according to claim 18, wherein the L2 connector is a single L2 
connector. 
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21. The method according to claim 18, wherein said determining which of the 
different types of network traffic accesses software services via a single data path 
comprises employing time division multiplexing to determine which of the different types 
of network traffic access the software services via the single data path. 

22. The method according to claim 18, wherein said determining which of the 
different types of network traffic accesses software services via a single data path 
comprises dynamically allocating fixed resources between among the different types of 
network traffic. 

23. The method according to claim 18, comprising: 

providing drivers associated with the plurality of different types of network traffic 
via a unified driver. 

24. A method for network interfacing, comprising: 

handling a plurality of different types of network traffic via a single Ethernet 
connector, wherein each of said plurality of different types of network traffic corresponds 
to a different network protocol; 

processing the plurality of different types of network traffic using a layer 2 (L2) 
processor, a layer 3 (L3) processor, a layer 4 (L4) processor and an upper layer protocol 
(ULP) processor; and 

providing a unified data and control path. 

25. The method according to claim 24, wherein the L2 processor comprises a 
single L2 network interface card (NIC). 

26. The method according to claim 24, wherein the L3 processor and the L4 
processor are combined into a single TCP processor. 



36 



Application Serial N° 10/652,327 
Appeal Brief in Response to Final Office Action of August 13, 2009 

27. The method according to claim 24, wherein the ULP processor comprises 
one or both of an Internet small computer system interface (iSCSI) processor and/or a 
remote direct memory access (RDMA) processor. 

28. The method according to claim 24, comprising: 

providing drivers associated with the plurality of different types of network traffic 
via a single unified driver. 

29. A unified driver, comprising: 

a computer program executable on a computer system, having at least one code 
section for arranging and processing network traffic, wherein the at least one code 
section causes the computer system to perform steps comprising: executing said at 
least one code section from said unified driver in said computer system to handle a 
plurality of different types of network traffics and/or network services via a single PCI 
bridge, wherein each of said plurality of different types of network traffic corresponds to 
a different network protocol, and the network services comprise two or more of a socket 
service, storage service, RDMA service or keyboard/video/mouse service. 

30. The unified driver computer program on a computer system of claim 29, 
comprising coupling said single PCI bridge to an integrated chip to concurrently process 
a plurality of network traffics. 

31. The unified driver computer program on a computer system of claim 30, 
wherein said plurality of network traffics comprise two or more of offload traffic, storage 
traffic, interprocess communication (IPC) traffic, management traffic and/or remote 
direct memory access (RDMA) traffic. 
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EVIDENCE APPENDIX 
(37C.F.R.§41.37(c)(1)(ix)) 

United States Pat. No. 6,226,680 ("Boucher"), entered into record by the 

Examiner in the 8/13/2009 Final Office Action. 

United States Pub. App. No. 2002/0198934 ("Kistler"), entered into record by 
the Examiner in the 8/13/2009 Final Office Action. 

Microsoft Winsock Direct and Protocol Offload on SANs, 03/03/2001 
("Microsoft"), entered into record by the Examiner in the 8/13/2009 Final 
Office Action. 

United States Pub. App. No. 2002/0041566 ("Yang"), entered into record by 
the Examiner in the 8/13/2009 Final Office Action. 

United States Pub. App. No. 2003/0046330 ("Hayes"), entered into record by 
the Examiner in the 8/13/2009 Final Office Action. 

Callaghan (NFS over RDMA) ("Callaghan"), entered into record by the 
Examiner in the 8/13/2009 Final Office Action. 
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RELATED PROCEEDINGS APPENDIX 
(37C.F.R.§41.37(c)(1)(x)) 

The Appellant is unaware of any related appeals or interferences. 



